-
Notifications
You must be signed in to change notification settings - Fork 207
chore: Implement credential type hierarchy #3738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Implement credential type hierarchy #3738
Conversation
64e7977
to
2420ece
Compare
24a610e
to
eeb1d5f
Compare
…credentials_hierarchy * CLOUDP-334161-service-accounts-dev: chore: Remove all attributes in assume_role except role_arn (#3745) chore: Fix SA dev branch merge (#3744) chore: Fix cleanup GHA after SA changes (#3742) chore: Fixes backport release issues (#3734) chore: Support generation of singleton resources with no delete operation (#3736) # Conflicts: # internal/config/client.go # internal/config/transport_test.go # internal/provider/provider_sdk2.go # internal/service/organization/resource_organization.go # internal/service/organization/resource_organization_test.go # internal/testutil/acc/factory.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR implements credential type hierarchy to refactor provider and client codebase, reducing duplication and inconsistencies. It also renames the token environment variable from MONGODB_ATLAS_OAUTH_TOKEN
to MONGODB_ATLAS_ACCESS_TOKEN
.
- Introduces new credential type hierarchy to reduce duplication and improve consistency
- Renames environment variable from
MONGODB_ATLAS_OAUTH_TOKEN
toMONGODB_ATLAS_ACCESS_TOKEN
- Refactors provider configuration logic to use the new credential system
Reviewed Changes
Copilot reviewed 16 out of 16 changed files in this pull request and generated 2 comments.
Show a summary per file
File | Description |
---|---|
internal/config/credentials.go | New file implementing credential type hierarchy with authentication methods and validation |
internal/config/credentials_test.go | Comprehensive test coverage for the new credential system |
internal/config/client.go | Refactored client creation to use new credential system with simplified API |
internal/provider/aws_credentials.go | Simplified AWS credential handling to return Credentials struct |
internal/provider/provider.go | Streamlined provider configuration using new credential hierarchy |
internal/provider/provider_sdk2.go | Simplified SDK v2 provider configuration with new credential system |
internal/testutil/acc/pre_check.go | Updated environment variable name for access token testing |
internal/testutil/acc/factory.go | Updated to use new client creation API |
internal/service/organization/resource_organization.go | Updated to use new client creation pattern |
internal/service/organization/resource_organization_test.go | Updated test to use new client creation API |
internal/service/eventtrigger/*.go | Updated realm client access pattern |
internal/config/service_account.go | Simplified token source creation with cleaner parameters |
internal/config/transport_test.go | Updated test to use new client creation API |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
return a.AssumeRoleARN != "" | ||
} | ||
|
||
type Vars struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: maybe rename this to a more meaningful name? providerVars maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Vars can be created from provider or environment variables using:
func NewEnvVars() *Vars # Create Vars from environment variables
getProviderVars # Create Vars from TFP provider
getSDKv2ProviderVars # Create Vars from SDKv2 provider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as I see it all these are provider vars, but can be inputed as provider inputs or env vars, so an option could be to have NewProviderEnvVars
, getProviderInputsVars
and getSDKv2ProviderInputsVars
and change Vars name to ProviderVars. Feel free to ignore if to convinced, this is a nit on naming 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think i understand the confusion, you call "provider inputs" when i say "provider". You're right that at the end of the day everything is about the provider :-)
"provider" var means defined in the Terraform provider config, e.g.:
provider "mongodbatlas" {
client_id = "my_id"
client_secret = "my_pass"
}
and Vars can be obtained from the provider config or environment variables, credentials decision order is done here:
if c := CoalesceCredentials(providerVars.GetCredentials(), envVars.GetCredentials()); c != nil { ...
if awsVars := CoalesceAWSVars(providerVars.GetAWS(), envVars.GetAWS()); awsVars != nil { | ||
awsCredentials, err := getAWSCredentials(awsVars) | ||
if err != nil { | ||
return nil, err | ||
} | ||
return awsCredentials, nil | ||
} | ||
if c := CoalesceCredentials(providerVars.GetCredentials(), envVars.GetCredentials()); c != nil { | ||
return c, nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very clear and easy to follow 💯
if data.AwsSecretAccessKeyID.ValueString() == "" { | ||
data.AwsSecretAccessKeyID = types.StringValue(MultiEnvDefaultFunc([]string{ | ||
"AWS_SECRET_ACCESS_KEY", | ||
"TF_VAR_AWS_SECRET_ACCESS_KEY", | ||
}, "").(string)) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(mentioned in complementary doc) only risk I see is that before we would allow combination of provider config + env variables, now it has to be all env vars or all provider config. For PAKs dont think a customer would ever do the mix, for the case of aws secret manager might be riskier. Would be transparent with a changelog entry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the changelog is clear now. I think being able to use a mix of env vars or provider inputs should not be supported, but good if it's clear in the changelog
AtlasV220240805 *admin20240805.APIClient // used in advanced_cluster to avoid adopting 2024-10-23 release with ISS autoscaling | ||
AtlasV220240530 *admin20240530.APIClient // used in advanced_cluster and cloud_backup_schedule for avoiding breaking changes (supporting deprecated replication_specs.id) | ||
AtlasV220241113 *admin20241113.APIClient // used in teams and atlas_users to avoiding breaking changes | ||
Realm *RealmClient |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice clean up removing config completely
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
APIx bot: a message has been sent to Docs Slack channel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM % copy
Co-authored-by: kanchana-mongodb <[email protected]>
5d09ca0
into
CLOUDP-334161-service-accounts-dev
Description
Implement credential type hierarchy.
Note: Review of this PR might be easier looking at the new files instead of the differences.
MONGODB_ATLAS_ACCESS_TOKEN
.Link to any related issue(s): CLOUDP-345764
Type of change:
Required Checklist:
Further comments